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(57) Abstract: Method and system for a service server to provide a service to a client. The client (C) sets up a secure session 
to an authentication server (CAP) and sends its identifier and a service request stating the required service. The authentication 

server verifies the client identifier and sends the service request to a service authorization server (DAP). The authorization server 

2? checks whether the required service may be provided and sends the authorized service request to the authentication server. The 
authentication server generates a token, associated with the authorized service request. Via the secure session, the authentication 
server sends the address of the relevant service server and the token. The client sends the token to the service server, which then sends 
£^ the token to the authentication server. The authentication server fetches the service request associated with the token and forwards it 
to the service server, after which the service server gives the client the required service. 
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Method and system for a service process to provide a service to a client 
BACKGROUND OF THE INVENTION 

The invention pertains to a method, or system, for a service process to provide a service to a 
5 client. The field of the invention is the delivery of services via computer networks. Authentication 
apd authorization of clients by servers pose a problem that has in theory been "solved", but in 
practice it is a persistent problem full of pitfalls. The practical result is that the secure (i.e. 
authenticated and authorized) provision of service occurs hardly at all on the Internet, and that 
users have little confidence in existing services. 

10 

Numerous causes are identifiable for this situation, including: 

when a service uses the SSL protocol to authenticate the customer and to make the 
service provisioning secure, SSL must be capable of transporting ("tunneling") the service 
provisioning protocol. This is not possible with protocols based on UDP. Simple UDP-based 
15 protocols are DNS (Domain Name Service), TFTP (Trivial File Transfer Protocol), SNMP 

(Simple Network Management Protocol), Syslog protocol, etc. More complex examples include 
video and audio streaming (such as RealAudio and RealVideo), multi-user gaming protocols 
and similar. 

when a service uses IPSEC, the following problem arises. IPSEC sets up a secure 
20 connection ("transport pipe") between two machines (computers, routers or combinations 

thereof), one that is separate from the services (client/servers) that use it. Several services may 
use the same IPSEC pipe. Use of the IPSEC authentication as an authentication for the service 
is similar to a person accepting the authenticity of the sender of a postcard because the 
postman is able to identify himself with means of identification. Apart from this, IPSEC is a far 
2 5 more difficult protocol than SSL to operate, both technically and from the point of view of 
security; 

when use is made of a combination of IPSEC and SSL for the above-mentioned 
purposes, the transmitted data is encrypted twice (once by IPSEC, once by SSL), which 
drastically reduces the speed of transport, and makes it more difficult to put the connection into 
30 operation. This quickly becomes unacceptable, particularly for real-time data transport 
(multimedia services); 

to the extent that authentication and authorization do take place, they are usually 
interwoven with an existing service, which causes greater problems as the service itself 
becomes larger and more complex. 

35 

SUMMARY OF THE INVENTION 

The invention aims to make it possible to: 
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1) modify in a simple way existing services that do little or no authentication/authorization, 
in such a way that they then possess robust authentication/authorization; 

2) develop new services whereby the authentication/authorization part is separated from 
the actual service provisioning part. 

5 

The invention comprises reusable components for implementing authentication and 
authorization. The invention solves the aforementioned problems by separating responsibilities 
from processes. A protocol will be defined that indicates how these parts communicate with 
each other in a way such that a service provider can provide his service to an authenticated and 
10 authorized customer. 



In a preferred embodiment of the invention, four processes are distinguishable, i.e.: 

a client process, for example a standard browser such as Microsoft Internet Explorer, 
hereafter also referred to as "client". This process is situated in the security domain of the 
15 service user; 

an authentication process, situated in the security domain of either the service provider 
or a trusted third party; 

a service authorization process (DAP). This process - the actual authorization process 
where it is determined whether a certain service can or cannot be provided to a certain client - is 
20 situated in the security domain of the service provider; 

a service process (DP), situated in the security domain of the service provider. 
According to the invention, a subset (at least one) of the processes may also be used. The 
method according to the invention consists of at least one of the following steps: 

a. the client sets up a secure session - an SSL session, for example - to an authentication 
2 5 process and sends a client identifier - an X.509 public key certificate, for example - and a 

service request indicating which service is required; 

b. the authentication process verifies the client identifier and sends to an authorization 
process the verified client identifier, preferably with a "degree of certainty" indication regarding 
the authenticity of the client identifier, and the service request; this allows the authorization 

30 process to know (1) which service is being requested, (2) by whom and (3) it has (preferably) a 
certain degree of certainty (indicated, for example, by Class I, II or III certificates) regarding the 
identity of client; 

c. the authorization process checks whether the service indicated in the service request 
can and may be provided to the client, and sends back to the authentication process the result 

35 of the check in the form of an authorized service request, together with a certain period of 
validity; the authorized service request represents authorization to start, within the period of 
validity, providing the service to the client; 
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d. the authentication process generates a token and associates it with the authorization 
issued in the previous step (the authorized service request); 

e. the authentication process then sends to the client the address of the service process 
concerned and the token, for example by means of an HTML page that contains that address 

5 and token as a hyperlink, whereby the browser of the client will be redirected to the (hyperlink) 
address of the service process; 

f. the client contacts the service process (by means of the hyperlink) and sends the token 
received from the authentication process (the session between the client and the verification 
process can be terminated); 

10 g. the service process sends the token received from the client to the authentication 
process; 

h. the authentication process fetches the authorized service request ("authorization") 
associated with the token, checks whether the period of validity is good and then sends the 
authorized service request to the service process. Note that this situation is exactly the same as 

15 if no authentication and authorization had taken place and the client process had sent the 

service request directly to the service process. This is because the client process started the 
session between the client and the service process, and the protocol used is the same protocol 
that the service process would have used in other cases for this purpose; 

i. the service process then provides the service required by the client. 

20 

The system according to the invention comprises the means for executing the above-mentioned 
steps in the method. The described invention has the following advantages: 

1) the invention uses standard protocols; 

2) the invention needs to be implemented only on the server side (i.e. where the 
25 authentication process, authorization process and service process have been activated). 

Popular browsers (such as Microsoft Internet Explorer, Netscape Navigator and similar) are 
usable without any modifications on the client side; 

3) no extra support (such as a helpdesk) is needed for end-users; 

4) with minima! modifications, any electronic service that does not (yet) carry out 

30 authentication/authorization can use the invention, regardless of the protocol that the service 
uses; 

5) the invention does not use sessions set up by a server and, by consequence, (a) 
requires no special modifications to firewalls, and (b) is also usable if the client is situated in a 
network connected to the Internet via Network Address Translation (NAT); 

35 6) the invention allows simple separation of business processes and operational 

processes, while the interfaces between the different processes are also very simple. This 
makes it easy to avoid a situation where a service is created as an inflexible monolithic entity. 
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REFERENCES 

- SSL ( ftp://dsjnternfc.net/intem This is an Internet draft 

dated 18th November 1996. The SSLv3 protocol has not been formally standardized but is the 
5 de facto standard. The protocol offers privacy and reliability between two communicating 
applications (processes). It allows client/server applications to communicate in a manner 
designed to prevent third parties being able to eavesdrop on communication, alter messages or 
add messages. In the protocol stack, SSL expects a reliable transport protocol (like TCP, but not 
UDP, for example) below it. 
10 - IPSEC ( http://www.ietf.org/rfc/rfc2401 .txt) . The purpose of IPSEC is to offer various 

security services for traffic on the IP layer, both in IPv4 and IPv6 environments. Although IPSEC 
can form part of service security, it is unable to make an entire service secure, because IPSEC 
operates at IP level, and it must be possible to guarantee the security of services also at higher 
levels; 

15 - closed systems also exist for authentication/authorization. See, for example, RABO 

Bank for electronic banking, the EasyPay system of Shell, Digital Postal Stamps of PTT Post 
and similar. Systems of this kind have the disadvantage that the customer needs additional 
hardware before being able to use the services. 

20 IMPLEMENTATION 

Figure 1 shows an implementation of the invention, representing a system with four processes, 
i.e. four hardware/software modules (computers, servers, terminals, etc) on which those 
processes run and can contact each other via a network (such as the Internet). 
Figure 1 shows a client process (C), implemented by means of a web browser like Microsoft 

25 Internet Explorer on a user's PC, a Client Authentication Process (CAP), implemented by means 
of procedures from standard libraries, a Service Authorization Process (DAP) and a Service 
Process (DP) that can provide a service requested by the user by means of his/her client (C). 
Each process falls within one security domain, i.e. one person or authority manages the process 
and bears the consequences of what the process does or does not do. Process C, for example, 

30 falls under the security domain of the user, while CAP falls under the security domain of the 
service provider (SP) concerned or a trusted third party, while the DAP and DP fall under the 
security domain of the service provider. 

In this context, a "protocol" is understood to be a method for allowing two (computer) processes 
to communicate with each other. These may be Internet protocols, for example, but also 
35 procedure calls (if the processes run on the same machine), or other protocols. 

The shown implementation of the invention uses the following communication protocols: 

SSL (Secure Sockets Layer Protocol) or TLS (Transport Layer Security protocol). These 



WO 03/007571 



PCT/EP02/07261 



5 

are well-known and well-documented protocols (see references); 

DSP (Domain Secure Protocol). This is not an existing protocol, but a "place holder" 
name for any protocol that either (1) provides communication between two processes within one 
and the same security domain, and (2) has been designated by the administrator of that security 
5 domain as "safe" for use within that security domain, or (1) provides communication between a 
process in the security domain of a TTP and a process in the security domain of the service 
provider concerned, and (2) has been designated by the administrators of these security 
domains as "safe" for use within those security domains; 

DSP1, a DSP protocol used between the CAP and DAP processes; 
10 - DSP2, a DPS protocol used between the CAP and DP processes. 

AP (Application Protocol). This is not an existing protocol, but a "place holder" name for 
the protocol between the client process (C) and the service process (DP). This protocol must 
satisfy the security requirements (and other requirements) laid down by the service provider for 
the protocol. 

15 

The procedure is as follows: 

a connection is set up between process C and CAP. This connection uses the SSL or 
TLS protocol. The protocol is set in such a way that during the set-up of this connection: 

(a) C authenticates the CAP based on a server certificate to be sent by the CAP that has 
20 been issued by a party known to C ("Trusted Third Party"); 

(b) CAP sends to C a list of client certificate issuers accepted by CAP. For each certificate 
type and issuer, the CAP further has the degree of certainty applied by the service provider for 
authentication of certificates of that type and issuer. 

CAP initiates a connection between CAP and DAP, using the DSP 1 protocol (see 

25 above). 

C initiates a connection between C and DP, using the AP protocol (see above), 
a connection is set up between service process DP and the CAP. This process uses the. 
DSP2 protocol (see above). DP or CAP can set up this connection. The invention assumes the 
existence of an (electronic) "contract" between users and service providers, specifying which 

30 services the DP may provide to the user and on what conditions. These conditions may possibly 
impose requirements regarding the type of certificate a client may submit for authentication, 
parameters that can influence the service, the charge the service provider requires from C for 
providing the required service, etc. The aforementioned service requests consist of a set of 
service parameters and take the form of a parameter list that may be added to a URL. Where 

35 reference is made to "authorization", this term comprises (1 ) the identity of the user (via the 

client C) for whom the authorization is intended, (2) a service request for which the authorization 
was issued, (3) a validity interval (i.e. a time interval within which the authorization is valid), and 
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(4) an IP address from where the authorization was requested. The service request takes the 
form of a parameter list added to a URL. The authorization further possesses the characteristic 
that the service provider (SP) has a sufficient degree of certainty that a client for whom the 
authorization was created is capable of obtaining access to the service within the validity 
5 interval. 

The "token" referred to above consists of a row of bits that the CAP creates based on an 
authorization, in such a way that the token possesses the following characteristics: 
(a) CAP can reproduce the authorization (which resulted in the creation of the token) on the 
basis of the token, at least during the time interval within which the authorization is valid; 
10 (b) the token is valid for such time as the authorization is valid; 

(c) the risk of a third party being able to guess a valid token is so small as to be negligible (for 
example, less than 2-50) 

(d) two or more different (valid) authorizations are not simultaneously associated with one 
15 and the same token. As CAP creates and also interprets the token, CAP is able to decide the 

data included in the token. The token size is limited (not in theory, but probably in practice) by: 
the size of the URL of the DP; 

the character set (ASCII) permissible for the token, and 

the maximum length of the URL permitted by the client browser. 

20 The secure hash (or part thereof) of an authorization converted to ASCII could be a good token. 
The diagram in Figure 2 illustrates how the presented system works: 
[1] the user surfs to the required service by entering the address (URL) (for example, 
www.service.com ) in the browser (client), which causes browser C to set up an SSL connection 
to the CAP server concerned, whereby the client C and the CAP server authenticate each other 

25 (see above under "setting up an SSL/TLS connection"). As a result of this action, CAP has at its 
disposal the identity of the user C (ID), the public key certificate of C against which the ID was 
checked, Alvl (being a parameter indicating to what extent service provider trusts this check), 
and the IP address (IP) from where C set up the connection. 

[2] C sends a service request sreq to CAP (via the SSL connection just set up). 

30 [3] CAP sends the sreq, ID, Alvl and IP to the DAP process (using the DSP1 protocol). 
[4] if DAP determines that the user C is not entitled to the service required by C (for 
example, because the required service provisioning is not defined by a contract), the protocol 
will end. If DAP determines that there is an entitlement to the service, DAP will set an alternative 
service request that (a) is covered by a contract and (b) resembles sreq as closely as possible. 

35 DAP further determines a time interval Tl (validity interval) within which service provisioning 
must start. 

[5] DAP sends authorization (comprising sreq', Tl, ID and IP) to CAP (using the DSP1 
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protocol). 

[5] DAP sends authorization A (consisting of sreq', Tl, Id and IP) to CAP (using the DSP1 
protocol); 

[6] CAP creates a token based on the authorization (A) provided by DAP, with all the 
5 properties of a token (see above). 

[7] CAP sends (in the already established SSL session) an HTML page to the client, 
containing a hyperlink to the server DP, such hyperlink including the token as a parameter, with 
everything occurring in a way such that the browser switches to this hyperlink after a waiting 
time of zero seconds. This action terminates the SSL session between C and CAP (the invented 
10 protocol does not yet terminate). 

[8] by interpreting this HTML page, the client browser sets up a session to the server DP 
according to the CAP protocol specified in the hyperlink. Also, the token is sent to DP by means 
of this protocol. 

[9] DP sends the token to CAP, as well as the IP address (IP) of the client that started the 
15 session (using the DSP 2 protocol). 

[10] CAP checks whether a valid authorization accompanies the token. If that is not the 
case, the protocol will terminate. Also, CAP will find out whether: 

IP is the same as the IP address (IP) stated in the authorization; 
the current time falls within time interval Tl stated in the authorization. 
20 If either of these items is incorrect, the protocol terminates. 

[11] CAP sends to DP the service request (sreq) stated in the authorization (using the DSP2 
protocol). 

[12] DP now starts providing service to C in accordance with the service request, using the 
AP protocol, and simultaneously the invented protocol ends. 

25 

The following comments need to be made: 

1 . if a process is situated in the security domain of a legal person, it means that the legal 
person is responsible for the security aspects of the process (i.e. he manages the security of 
this process and bears the consequences of what the process does or does not do - 

30 unintentionally or otherwise - with regard to security). 

2. the "degree of certainty" Alvi indicates how much trust the business has in the statement 
that "the customer is called ID". After all, this trust may depend on the degree to which the 
certificate issuer checked the identity, and this circumstance is different in the case of, for 
example, Class I, II and III certificates. 

35 3. although the standard refers to certificate issuers, the situation in practice is that one 
certificate issuer may issue several types of certificates ( for example, Class I, II and III 
certificates), whereby the conditions on which a certificate type is issued differ from those 
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attached to a different type of certificate. Consequently, the trust that a service provider has in 
different certificate types may differ, and every certificate type should have a "degree of 
certainty" Alvl. However, the "distinguished name" of the issuer as it occurs in the certificate is 
also used to indicate these certificate types. Therefore, it is possible to suffice in this instance 
5 with sending a list of certificate issuers. 
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CLAIMS 

1 . Method for a service process to provide a service to a client, characterized by the 
following steps: 

5 a. the client sets up a secure session to an authentication process and sends a client 
identifier and a service request indicating which service is required; 

b. the authentication process verifies the client identifier and sends to an authorization 
process the verified client identifier and the service request; 

c. the authorization process checks whether the service indicated in the service request 
10 can and may be provided to the client, and sends the result of the check to the authentication 

process in the form of an authorized service request that includes a validity period; 

d. the authentication process generates a token that is associated with the authorized 
service request; 

e. via the secure session, the authentication process sends to the client the address of the 
15 service process concerned and the token; 

f. the client contacts the service process and sends the service process the token 
received from the authentication process; 

g. the service process sends the authentication process the token received from the client; 

h. the authentication process fetches the authorized service request associated with the 
20 token, checks whether the validity period is good, and then sends the authorized service request 

to the service process; 

i. the service process then provides the service required by the client. 

2. Method according to claim 1 , with the characteristic that the authentication process in 
25 the step described above at b. sends to the authorization process, in addition to the verified 

client identifier, a "degree of certainty" indication concerning the authenticity of the client 
identifier. 

3. System for a service server to provide a service to a client, with the characteristic that: 
30 a. the client includes means for setting up a secure session to an authentication server 

and for sending to that authentication server a client identifier and a service request stating 
which service is required; 

b. the authentication server includes means for verifying the client identifier received from 
the client and for sending the verified client identifier and the service request to an authorization 

3 5 server; 

c. the authorization server includes means for checking whether the service stated in the 
service request can and may be provided to the client, and means for sending back to the 
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authentication server the result of the check in the form of an authorized service request, 
provided with a validity period determined by the authorization server; 
d. the authentication server includes means for generating a token, associated with the 
authorized service request; 
5 e. the authentication server includes means for sending the client, via the secure session, 
the address of the relevant service server and the token; 

f. the client includes means for sending the received token to the service server; 

g. the service server includes means for sending to the authentication server the token 
received from the client; 

10 h. the authentication server includes means for fetching the authorized service request 
associated with the token, checking whether the validity period is good, and then sending the 
authorized service request to the service server; 

i. the service server includes means for subsequently providing the required service to the 
client. 

15 

4. System according to claim 3, with the characteristic that the authentication server, in 
addition to including the means mentioned above at b. for verifying the client identifier received 
from the client and sending the verified client identifier and the service request to an 
authorization server, further includes means for calculating a "degree of certainty" indication 
20 regarding the authenticity of the client identifier and for sending that indication to the 
authorization server: 



WO 03/007571 



PCT/EP02/07261 




WO 03/007571 



PCT/EP02/07261 



2/2 



Ph 

Q 



7T\ 



O 



Ph 



Oh 

Q 



"71^ 



Cm 



Ph 



<L> 



¥— i 



© 



o 



o 

■ T-H 



't-H 

1/3 





<S| <0 OO Cft ^H 



INTERNATIONAL SEARCH REPORT 



Interatrial Application No 

PCT/EP 02/07261 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC 7 H04L29/06 



According to International Patent Classification (IPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 

IPC 7 H04L G06F 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 



Electronic data base consulted during the international search (name of data base and, where practical, search terms used) 

EPO-Internal, WPI Data, PAJ, COMPENDEX, INSPEC 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 0 Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



WO 00 69110 A (SUN MICROSYSTEMS INC) 
16 November 2000 (2000-11-16) 
page 13, line 1 -page 14, line 6 
page 23, line 12 -page 27, line 20 

WO 99 00958 A (PARKINSON DAVID WILLIAM 
;TIBBITT EG6LET0N ROBERT IAN (GB); 
ROBERTS) 7 January 1999 (1999-01-07) 
abstract 

page 2, line 8 - line 26 
page 5, line 22 -page 8, line 3 
page 10, line 25 -page 11, line 1 
page 11, line 16 -page 12, line 14 

W0 01 27709 A (HEIKKONEN ISMO ;PITKAENEN 
KIMMO (FI); SONERA 0YJ (FI)) 
19 April 2001 (2001-04-19) 
page 5, line 14 -page 7, line 3 

_/- 



1,3 



1,3 



1,3 



X 



Further documents are listed in the continuation of box C. 



0 



Patent family members are listed in annex. 



° Special categories of cited documents : 

"A* document defining the general state of the art which Is not 
considered to be of particular relevance 

■E 1 earlier document but published on or after the international 
filing date 

"L" document which may throw doubts on priority claim(s) or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

'O* document referring to an oral disclosure, use, exhibition or 
other means 

"P l document published prior to the international filing date but 
laterthan the priority date claimed 



"T 1 later document published after the international filing date 
or priority date and not In conflict with the application but 
cited to understand the principle or theory underlying the 
invention 

"X" document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
involve an Inventive step when the document is taken alone 

■Y" document of particular relevance; the claimed invention 

cannot be considered to involve an inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
In the art. 

■&" document member of the same patent family 



Date of the actual completion of the international search 



27 September 2002 



Date of mailing of the international search report 



07/10/2002 



Name and mailing address of the ISA 

European Patent Office, P.B. 5818 Patentlaan 2 
NL - 2280 HV Rijswijk 
Tel. (+31-70) 340-2040, Tx. 31 651 epo nl, 
Fax: (+31-70) 340-3016 



Authorized officer 



Peeters, D 



Form PCT/ISA/210 (second sheet) (July 1992) 



INTERNATIONAL SEARCH REPORT 



Interatrial Application No 

PCT/EP 02/07261 



C(Contlnuation) DOCUMENTS CONSIDERED TO BE RELEVANT 



Category • Citation of document, with indication.where appropriate, of the relevant passages 



Relevant to claim No. 



SAMAR V: "Single sign-on using cookies 
for Web applications" 

ENABLING TECHNOLOGIES: INFRASTRUCTURE FOR 
COLLABORATIVE ENTERPRISES, 1999. (WET ICE 
'99). PROCEEDINGS. IEEE 8TH INTERNATIONAL 
WORKSHOPS ON STANFORD, CA, USA 16-18 JUNE 
1999, LOS ALAMITOS, CA, USA, IEEE COMPUT. 
SOC US 

16' June 1999 (1999-06-16), pages 158-163, 
XP002179650 
ISBN: 0-7695-0365-9 

page 160, left-hand column, paragraph 6.1 
-page 161, right-hand column 

WO 99 22317 A (UNIFREE LLC) 

6 May 1999 (1999-05-06) 

page 16, line 17 -page 19, line 17; 

figures 6,7 

W0 01 11845 A (SUN MICROSYSTEMS INC) 
15 February 2001 (2001-02-15) 
page 2, line 14 -page 3, line 9 
page 5, line 16 - line 26 



1,3 



1,3 



2,4 



Form PCT/ISA/210 (continuation of second sheet) (July 1992) 



INTERNATIONAL SEARCH REPORT 

^information on patent family members 


Interatrial Application No 

PCT/EP 02/07261 


Patent document 
cited In search report 


Publication 
date 


Patent family 
member(s) 


Publication 
date 



WO 0069110 



16-11-2000 US 
AU 
EP 
WO 
US 



6226752 Bl 
4986200 A 
1177654 Al 
0069110 Al 
2001037469 Al 



01-05-2001 
21-11-2000 
06-02-2002 
16-11-2000 
01-11-2001 



WO 


9900958 


A 


07- 


-01- 


-1999 


WO 


9900958 Al 


07-01-1999 














AU 


8224498 A 


19-01-1999 














EP 


0992145 Al 


12-04-2000 














WO 


9900960 Al 


07-01-1999 


wo 


0127709 


A 


19- 


-04- 


-2001 


FI 


992196 A 


13-04-2001 














AU 


7793000 A 


23-04-2001 














WO 


0127709 A2 


19-04-2001 


wo 


9922317 


A 


06- 


-05- 


-1999 


US 


2001043599 Al 


22-11-2001 














WO 


9922317 A2 


06-05-1999 


wo 


0111845 


A 


15- 


-02- 


-2001 


AU 


6752700 A 


05-03-2001 














EP 


1205057 A2 


15-05-2002 














WO 


0111845 A2 


15-02-2001 



Form PCT/ISA/210 (patent family annex) (July 1902) 



